[レポート]Builders' session「データ境界の課題」に参加してきました。#SEC307

こんにちは。中村です。
本記事は　Builders' session「Data perimeter challenge」 の参加レポートになります。

概要

Build actual data perimeter policies in real time based on provided requirements. Test that your policies work with an assessment tool that evaluates if you’ve effectively completed the data perimeter requirement. Leave this builders’ session understanding the tools that are available for you to ensure that only trusted identities are accessing trusted resources from expected networks. You must bring your laptop to participate.
［機械翻訳］
提供された要件に基づいてリアルタイムで実際のデータ境界ポリシーを構築します。データ境界要件を効果的に完了したかどうかを評価する評価ツールでポリシーの動作をテストします。信頼できるIDのみが期待されるネットワークから信頼できるリソースにアクセスすることを確実にするために利用可能なツールを理解してこのビルダーセッションを終えましょう。参加にはラップトップの持参が必要です。

スピーカー

• Rishi Mehrotra, Sr. Product Manager Technical, Amazon
• Asaf Lerner, Sr. Identity GTM Specialist, AWS
• Achraf Moussadek Kabdani, Security Specialist, AWS
• Tatyana Yatskevich, Principal Solutions Architect, AWS
• Prashant Dongale, Senior SDM, Amazon

レベル

• 300

内容

4つのシナリオが提供され、それぞれについて付与する権限を学習しました。

シナリオ1: 設定ミスによる意図しないデータの漏洩

AWSにはリソースに対するIAMポリシーがあります。
意図していない設定をしてしまうと、組織外から不正なアクセスをされてしまいます。

下記のポリシーが提供され、適切な値を設定することが課題となります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid":"EnforceOrgsIdentities",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "<IF THE CALL IS BY AN IDENTITY IN YOUR ORG>": "<TO_BE_FILLED>"
        }
      }
    }
  ]
}

シナリオ1では、
リソースコントロールポリシーに対してorganization IDを利用した制限するとよさそうです。
S3に接続できるリソースを組織に限定するのです。

今回はデータの境界を組織部分においているため、組織レベルで制限を実施しています。
境界自体をアカウントやユーザに変更すると、設定内容も変更する必要があります。

シナリオ2: 個人の認証情報使用による意図しないデータの漏洩

このシナリオでは、個人の認証情報を社内に持ち込まれた場合に、
その認証情報を利用してVPC内部から外部にデータを漏洩することを防ぎます。

下記のポリシーが提供され、適切な値を設定することが課題となります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRequestsByOrgsIdentities",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "<IF THE CALL IS BY AN IDENTITY IN YOUR ORG>": "<TO_BE_FILLED>"
        }
      }
    }
  ]
}

シナリオ2では、
VPCエンドポイントポリシーに対して、organization IDを設定する良いです。
VPCから組織外部への通信を制限することで、VPCからのデータ漏洩を防げます。

シナリオ3: 企業の認証情報使用による意図しないデータの漏洩

このシナリオでは、組織内の認証情報を利用して、組織外のアカウントに対してデータを漏洩することを防ぎます。

下記のポリシーが提供され、適切な値を設定することが課題となります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceResourcePerimeter",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "<IF THE REQUESTED RESOURCE IS IN YOUR ORG>": "<TO_BE_FILLED>"
        }
      }
    }
  ]
}

シナリオ3では、SCPを利用して組織外の実行権限を拒否すると実現できそうです。
もし組織内にグループ企業など複数の企業のリソースが存在する場合は、OUまで指定して設定すると良いでしょう。

シナリオ4: 盗まれた認証情報による意図しないデータアクセス

このシナリオでは、認証情報が漏洩した場合に、データ漏洩を防ぐ設定を検討します。

下記のポリシーが提供され、適切な値を設定することが課題となります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnforceNetworkPerimeter",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddressIfExists": {
          "<IF THE CALL COMES FROM YOUR IP>": "<TO_BE_FILLED>"
        },
        "StringNotEqualsIfExists": {
          "<IF THE CALL COMES FROM YOUR VPC>": "<TO_BE_FILLED>"
        },
        "BoolIfExists": {
          "<IF THE CALL IS BY AN AWS SERVICE ON YOUR BEHALF>": "<TO_BE_FILLED>"
        },
        "StringEquals": {
          "aws:PrincipalTag/<TO_BE_FILLED>": "<TO_BE_FILLED>"
        }
      }
    }
  ]
}

シナリオ4では、SCPを利用して各種設定をするとよさそうです。
シナリオに含まれる、CIDR範囲、VPCをまずは指定してあげます。

この課題に取り組んでいるとき、私は"BoolIfExists"と"StringEquals"に設定する内容がすぐに思いつきませんでした。

各課題にはヒントがあるのですが、ヒントをみて解決しました。
"BoolIfExists"には、AWSサービスからの通信かどうかを確認します。AWSサービス以外からの通信を拒否することで、影響範囲を限定します。
"StringEquals"には、aws:PrincipalTag/tag-keyを利用して特定のタグからの通信に限定します。これによって、影響範囲を限定します。
タグに関しては、設定するキーと値も合わせて漏洩すると意味が薄れます。タグの設定は、更なるセキュリティ強化として設定すると良いかと思います。

課題の趣旨とは異なりますが、本シナリオで漏洩した権限が管理者権限であった場合、そもそもIAM権限自体を改竄することが可能となります。
本シナリオの前提として、認証情報が漏洩しないような対策/リスク低減策をまずすることをお勧めします。

感想

今回のセッションでは、データ境界について検討しました。
IAM権限などは初回に設定した後でそのままになっているユーザも多いのではとふと思いました。これを機に、見直してみるのも良さそうです。